Hi, I am replacing stepper motors with brushed DC motors to get more channels out of my SnapAMP

There is a nice guide here:
https://dynomotion.com/Help/ExampleConfigurations/BrushServoSnapAmp.htm

and yet, I am having trouble.
The encoder counts correctly when turning the shaft.
The motor is wired into OUT0 and OUT1. The Output channel is set to 8.

No programs have been written into the kflop. Upon power up, I open the configuration screen in kmotion and configure the channels as below. Basically like here:
https://dynomotion.com/Help/ExampleConfigurations/ConfigEncoderBrush.PNG

 

Except for a different encoder channel.
"Download" enables channel 4 and I can see the encoder count if I move the shaft. There is no resistance on the shaft.

Then I clear the filters, as in the example.

Then I set the step response screen like this:
https://dynomotion.com/Help/ExampleConfigurations/StepScreenLowGain.PNG

 

Except that V= 10000 because my encoder has 800 counts/rev, not 4000 as in the example. I then press enable with the motor power supply turned off to write the configuration to kflop.

Next, I disable the axis using the checkbox in the 'Axis' screen and set the current limits as listed here:
https://dynomotion.com/Help/ExampleConfigurations/SetHighCurLimits.PNG

 

Then I turn on the motor power supply and put in the following command in the console:
pwmc8=20 (tried higher numbers, but I did not want to blast the motor with the full current right away.)

But the motor will not turn....
I tried to use another output channel (11) in case this was damaged, but the behavior is the same.
I also put the motor to a DC bench power supply to make sure it was working. It works fine.

Any ideas how I should proceed?

I have a small bit of extra information.

I switched motors (I had another identical unit), just in case it was the motor somehow, but have no change in result.
I switched back to stepper motors to check for breakage in the SnapAMP drive circuit. The steppers work just fine.

I noticed that the pwmc8 command changes the PWM setting in the Analog I/O window to the correct number, but no current is flowing. I did check with a voltmeter right on the screw terminal, and there is no voltage going out. Input voltage is 56V in Analog I/O window.

I would appreciate any ideas.

Have you set the Peak Current Limits in SnapAmp via a C Program?

Is the "fault" LED on SnapAmp on?  One LED (I'm Alive) should be blinking and the other (fault) should be off.

See the "Set High Cur Limits.c" example.

Supply Voltage Clamping should also be set to protect SnapAmp and your supply from overvoltage from regenerative braking.  But that wouldn't prevent the motor from driving. 

Regards

TK

 

I have a small bit of extra information.

I switched motors (I had another identical unit), just in case it was the motor somehow, but have no change in result.
I switched back to stepper motors to check for breakage in the SnapAMP drive circuit. The steppers work just fine.

I noticed that the pwmc8 command changes the PWM setting in the Analog I/O window to the correct number, but no current is flowing. I did check with a voltmeter right on the screw terminal, and there is no voltage going out. Input voltage is 56V in Analog I/O window.

I would appreciate any ideas.

Thank you for your reply! I did set the peak limits at first, but stopped doing it somewhere along the lines because I thought the default setting is unlimited.
Anyway, after making sure I set the current limit to level 8, what happens is that on enable the current in the Analog I/O window rapidly changes between +- 5 A. The shaft is easily turned by hand, but the motor gets hot fast. The pwmc8 command can cause the current to start but pwmc8=0 does not turn it off, only the Axis checkbox can do that.

Order of steps:
1 - run c program with current limits and oversupply protection
2 - download configuration
3 - set step response
4 - disable axis checkbox
5 - turn on motor power supply
6 - run pwmc8=30. This now causes +-5A current. PWM=2.9%. Motor gets hot. Shaft turns easily by hand but otherwise stays still.

7 - pwmc8=0 does not turn off current, even though the the Analog I/O window now shows PWM=0
8 - checking, then unchecking the enable in the Axis window can get the current back to 0A

What am I doing wrong?

I forgot to mention that the heartbeat LED keeps blinking and the fault LED stays off the whole time.

Your steps seem reasonable to me except current limit 8 isn't a valid setting (use 9 or higher) and steps 2-4 are not necessary for your test.  But I don't expect those are the issue.

I suspect you have a very small low inductance motor?

The pwmc command attempts to drive a specified current.  To do this a digital current loop in the SnapAmp FPGA is used to monitor the current and dynamically adjust the pwm duty cycle (which is basically a voltage) to attempt to get the desired current to flow.  Too low of inductance will cause the current to change too rapidly and cause overshoot of the target and to go unstable in oscillation.   The FPGA does allow setting a feedback gain which is something we might try.

You might try using pwmr commands.  This mode directly sets the pwm duty cycle to what you specify.  There is no control loop and so nothing can go unstable.  This is like controlling the voltage rather than current.  This will work with even 0 inductance loads like a light bulb.

Do you know the inductance and resistance of your motors?

Regards

TK

 

Thank you for your reply! I did set the peak limits at first, but stopped doing it somewhere along the lines because I thought the default setting is unlimited.
Anyway, after making sure I set the current limit to level 8, what happens is that on enable the current in the Analog I/O window rapidly changes between +- 5 A. The shaft is easily turned by hand, but the motor gets hot fast. The pwmc8 command can cause the current to start but pwmc8=0 does not turn it off, only the Axis checkbox can do that.

Order of steps:
1 - run c program with current limits and oversupply protection
2 - download configuration
3 - set step response
4 - disable axis checkbox
5 - turn on motor power supply
6 - run pwmc8=30. This now causes +-5A current. PWM=2.9%. Motor gets hot. Shaft turns easily by hand but otherwise stays still.

7 - pwmc8=0 does not turn off current, even though the the Analog I/O window now shows PWM=0
8 - checking, then unchecking the enable in the Axis window can get the current back to 0A

What am I doing wrong?

---In DynoMotion@yahoogroups.com, <tk@...> wrote :

Have you set the Peak Current Limits in SnapAmp via a C Program?

Is the "fault" LED on SnapAmp on?  One LED (I'm Alive) should be blinking and the other (fault) should be off.

See the "Set High Cur Limits.c" example.

Supply Voltage Clamping should also be set to protect SnapAmp and your supply from overvoltage from regenerative braking.  But that wouldn't prevent the motor from driving. 

Regards

TK

On 8/31/2017 11:23 PM, homeloan@... [DynoMotion] wrote:

 

I have a small bit of extra information.

I switched motors (I had another identical unit), just in case it was the motor somehow, but have no change in result.
I switched back to stepper motors to check for breakage in the SnapAMP drive circuit. The steppers work just fine.

I noticed that the pwmc8 command changes the PWM setting in the Analog I/O window to the correct number, but no current is flowing. I did check with a voltmeter right on the screw terminal, and there is no voltage going out. Input voltage is 56V in Analog I/O window.

I would appreciate any ideas.

Attachments :

Maxon_2015_2016_Catalog-14984.jpeg

You hit the nail on the head! pwmr rotates the motor just fine!
I don't have an LCR meter to measure inductance. However, This is a private part number Maxon RE 35. I am attaching the data sheet for the standard part numbers. When putting a DC bench supply on the motor at 30V, I get about 7875 RPM. So that points to this motor being between part numbers 323890 and 273753.

That would put the inductance between 0.19 and 0.34 mH. Does that make sense?
I can't get a consistent reading on the resistance with my Ohmmeter. If this is important, I can try to borrow another one.

Thanks for the help!!

That's pretty low inductance.  SnapAmp PWMs run at 33KHz or on and off every 30us.  With a 56V supply applied to a 0.19mH inductor for 30us the current will ramp to:

I = V x T / L = 56 x 30e-6 / 0.19e-3 = 8.84 Amps

Even with smaller duty cycles the current ripple will be large especially for such small/low current motors.

Is there a reason you chose these motors?

KFLOP doesn't have a built in "DC Servo" mode for SnapAmp PWMR mode.  But you can output to that mode yourself using a User Program similar to the examples outputting to the KFLOP PWMs.  See the  OutputToPWM3axis.c example.  The Axis is configured as "No Output" but you then write the output to the SnapAmp PWMR yourself in a loop.  Using calls to:

// On board Power Amp PWM control

#define MAX_PWMR_VALUE 400        // Max value for PWMs in Recirculate mode
void WritePWMR(int ch, int v);  // Write to PWM - Recirculate mode (+ or - power then shorted)

Where ch would be in the range 8 .. 11.  And v in the range -400 .. +400

Let us know how much of this makes sense.

Regards
TK

 

You hit the nail on the head! pwmr rotates the motor just fine!
I don't have an LCR meter to measure inductance. However, This is a private part number Maxon RE 35. I am attaching the data sheet for the standard part numbers. When putting a DC bench supply on the motor at 30V, I get about 7875 RPM. So that points to this motor being between part numbers 323890 and 273753.

That would put the inductance between 0.19 and 0.34 mH. Does that make sense?
I can't get a consistent reading on the resistance with my Ohmmeter. If this is important, I can try to borrow another one.

Thanks for the help!!

---In DynoMotion@yahoogroups.com, <tk@...> wrote :

Your steps seem reasonable to me except current limit 8 isn't a valid setting (use 9 or higher) and steps 2-4 are not necessary for your test.  But I don't expect those are the issue.

I suspect you have a very small low inductance motor?

The pwmc command attempts to drive a specified current.  To do this a digital current loop in the SnapAmp FPGA is used to monitor the current and dynamically adjust the pwm duty cycle (which is basically a voltage) to attempt to get the desired current to flow.  Too low of inductance will cause the current to change too rapidly and cause overshoot of the target and to go unstable in oscillation.   The FPGA does allow setting a feedback gain which is something we might try.

You might try using pwmr commands.  This mode directly sets the pwm duty cycle to what you specify.  There is no control loop and so nothing can go unstable.  This is like controlling the voltage rather than current.  This will work with even 0 inductance loads like a light bulb.

Do you know the inductance and resistance of your motors?

Regards

TK

On 9/1/2017 4:19 PM, homeloan@... [DynoMotion] wrote:

 

Thank you for your reply! I did set the peak limits at first, but stopped doing it somewhere along the lines because I thought the default setting is unlimited.
Anyway, after making sure I set the current limit to level 8, what happens is that on enable the current in the Analog I/O window rapidly changes between +- 5 A. The shaft is easily turned by hand, but the motor gets hot fast. The pwmc8 command can cause the current to start but pwmc8=0 does not turn it off, only the Axis checkbox can do that.

Order of steps:
1 - run c program with current limits and oversupply protection
2 - download configuration
3 - set step response
4 - disable axis checkbox
5 - turn on motor power supply
6 - run pwmc8=30. This now causes +-5A current. PWM=2.9%. Motor gets hot. Shaft turns easily by hand but otherwise stays still.

7 - pwmc8=0 does not turn off current, even though the the Analog I/O window now shows PWM=0
8 - checking, then unchecking the enable in the Axis window can get the current back to 0A

What am I doing wrong?

---In DynoMotion@yahoogroups.com, <tk@...> wrote :

Have you set the Peak Current Limits in SnapAmp via a C Program?

Is the "fault" LED on SnapAmp on?  One LED (I'm Alive) should be blinking and the other (fault) should be off.

See the "Set High Cur Limits.c" example.

Supply Voltage Clamping should also be set to protect SnapAmp and your supply from overvoltage from regenerative braking.  But that wouldn't prevent the motor from driving. 

Regards

TK

On 8/31/2017 11:23 PM, homeloan@... [DynoMotion] wrote:

 

I have a small bit of extra information.

I switched motors (I had another identical unit), just in case it was the motor somehow, but have no change in result.
I switched back to stepper motors to check for breakage in the SnapAMP drive circuit. The steppers work just fine.

I noticed that the pwmc8 command changes the PWM setting in the Analog I/O window to the correct number, but no current is flowing. I did check with a voltmeter right on the screw terminal, and there is no voltage going out. Input voltage is 56V in Analog I/O window.

I would appreciate any ideas.

Thank you for your reply! All that makes sense.

I chose those motors because I wanted
1 - switch to DC motors so I can drive more motors with the SnapAMP
2 - would like 10+ KRPM rated motors
3 - affordable/available to me

That lead me to the RE 35 motors available on eBay.

Commanding current is better because it directly relates to torque/acceleration.  Commanding Voltage commands the motor current in a similar way but the current will be affected somewhat by the Motor's back-emf, inductance, and resistance.  The servo feedback loop will normally correct for all these by adjusting the output until the motor accelerates in the manner required.   It adds other things that the servo has to deal with.  I'd expect it to only have a minor effect on performance.

Let us know how well it works

Regards

TK

 

Thank you for your reply! All that makes sense.

I chose those motors because I wanted
1 - switch to DC motors so I can drive more motors with the SnapAMP
2 - would like 10+ KRPM rated motors
3 - affordable/available to me

That lead me to the RE 35 motors available on eBay.

I implemented it the way you suggested, and it works great! Time to put the motor into the CNC machine...

Is doing it this way going to affect servo performance?

Also, one more time, thanks for the world-class support you provide for your products!

---In DynoMotion@yahoogroups.com, <tk@...> wrote :

That's pretty low inductance.  SnapAmp PWMs run at 33KHz or on and off every 30us.  With a 56V supply applied to a 0.19mH inductor for 30us the current will ramp to:

I = V x T / L = 56 x 30e-6 / 0.19e-3 = 8.84 Amps

Even with smaller duty cycles the current ripple will be large especially for such small/low current motors.

Is there a reason you chose these motors?

KFLOP doesn't have a built in "DC Servo" mode for SnapAmp PWMR mode.  But you can output to that mode yourself using a User Program similar to the examples outputting to the KFLOP PWMs.  See the  OutputToPWM3axis.c example.  The Axis is configured as "No Output" but you then write the output to the SnapAmp PWMR yourself in a loop.  Using calls to:

// On board Power Amp PWM control

#define MAX_PWMR_VALUE 400        // Max value for PWMs in Recirculate mode
void WritePWMR(int ch, int v);  // Write to PWM - Recirculate mode (+ or - power then shorted)

Where ch would be in the range 8 .. 11.  And v in the range -400 .. +400

Let us know how much of this makes sense.

Regards
TK

On 9/1/2017 9:59 PM, homeloan@... [DynoMotion] wrote:

 

You hit the nail on the head! pwmr rotates the motor just fine!
I don't have an LCR meter to measure inductance. However, This is a private part number Maxon RE 35. I am attaching the data sheet for the standard part numbers. When putting a DC bench supply on the motor at 30V, I get about 7875 RPM. So that points to this motor being between part numbers 323890 and 273753.

That would put the inductance between 0.19 and 0.34 mH. Does that make sense?
I can't get a consistent reading on the resistance with my Ohmmeter. If this is important, I can try to borrow another one.

Thanks for the help!!

---In DynoMotion@yahoogroups.com, <tk@...> wrote :

Your steps seem reasonable to me except current limit 8 isn't a valid setting (use 9 or higher) and steps 2-4 are not necessary for your test.  But I don't expect those are the issue.

I suspect you have a very small low inductance motor?

The pwmc command attempts to drive a specified current.  To do this a digital current loop in the SnapAmp FPGA is used to monitor the current and dynamically adjust the pwm duty cycle (which is basically a voltage) to attempt to get the desired current to flow.  Too low of inductance will cause the current to change too rapidly and cause overshoot of the target and to go unstable in oscillation.   The FPGA does allow setting a feedback gain which is something we might try.

You might try using pwmr commands.  This mode directly sets the pwm duty cycle to what you specify.  There is no control loop and so nothing can go unstable.  This is like controlling the voltage rather than current.  This will work with even 0 inductance loads like a light bulb.

Do you know the inductance and resistance of your motors?

Regards

TK

On 9/1/2017 4:19 PM, homeloan@... [DynoMotion] wrote:

 

Thank you for your reply! I did set the peak limits at first, but stopped doing it somewhere along the lines because I thought the default setting is unlimited.
Anyway, after making sure I set the current limit to level 8, what happens is that on enable the current in the Analog I/O window rapidly changes between +- 5 A. The shaft is easily turned by hand, but the motor gets hot fast. The pwmc8 command can cause the current to start but pwmc8=0 does not turn it off, only the Axis checkbox can do that.

Order of steps:
1 - run c program with current limits and oversupply protection
2 - download configuration
3 - set step response
4 - disable axis checkbox
5 - turn on motor power supply
6 - run pwmc8=30. This now causes +-5A current. PWM=2.9%. Motor gets hot. Shaft turns easily by hand but otherwise stays still.

7 - pwmc8=0 does not turn off current, even though the the Analog I/O window now shows PWM=0
8 - checking, then unchecking the enable in the Axis window can get the current back to 0A

What am I doing wrong?

---In DynoMotion@yahoogroups.com, <tk@...> wrote :

Have you set the Peak Current Limits in SnapAmp via a C Program?

Is the "fault" LED on SnapAmp on?  One LED (I'm Alive) should be blinking and the other (fault) should be off.

See the "Set High Cur Limits.c" example.

Supply Voltage Clamping should also be set to protect SnapAmp and your supply from overvoltage from regenerative braking.  But that wouldn't prevent the motor from driving. 

Regards

TK

On 8/31/2017 11:23 PM, homeloan@... [DynoMotion] wrote:

 

I have a small bit of extra information.

I switched motors (I had another identical unit), just in case it was the motor somehow, but have no change in result.
I switched back to stepper motors to check for breakage in the SnapAMP drive circuit. The steppers work just fine.

I noticed that the pwmc8 command changes the PWM setting in the Analog I/O window to the correct number, but no current is flowing. I did check with a voltmeter right on the screw terminal, and there is no voltage going out. Input voltage is 56V in Analog I/O window.

I would appreciate any ideas.

I mounted the motor on the CNC and it works pretty well. However, I don't seem to be able to use the step response screen. I have been tuning the loop by trial and error, setting the parameters in the c code. However, setting a motion in the step response screen causes the motor not to move at all (small movements), or run away (large movements) - kind of like when the servo gain is inverted. However, the thing happens independent of servo gain sign - and anyway, the loop works when everything is set in code so the gain there is correct. I am probably overflowing a variable somewhere or something.

Here the code that works well enough to let me jog the axis in kmotionCNC:

#include "KMotionDef.h"
 
int main() 
{
    WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT0,9);  // current limit
    WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT1,9);  // current limit
        WriteSnapAmp(SNAP0+SNAP_SUPPLY_CLAMP0 ,SNAP_CONVERT_VOLTS_TO_ADC(70.0));
    WriteSnapAmp(SNAP0+SNAP_SUPPLY_CLAMP1 ,SNAP_CONVERT_VOLTS_TO_ADC(70.0));
    WriteSnapAmp(SNAP0+SNAP_SUPPLY_CLAMP_ENA0,1);
    WriteSnapAmp(SNAP0+SNAP_SUPPLY_CLAMP_ENA1,1);
     
    ch4->InputMode=ENCODER_MODE;
    ch4->OutputMode=NO_OUTPUT_MODE;
    ch4->Vel=10000;
    ch4->Accel=1e+05;
    ch4->Jerk=1e+07;
    ch4->P=10.0;
    ch4->I=0.001;
    ch4->D=0;
    ch4->FFAccel=0;
    ch4->FFVel=0;
    ch4->MaxI=200;
    ch4->MaxErr=1e+06;
    ch4->MaxOutput=400;
    ch4->DeadBandGain=1;
    ch4->DeadBandRange=0;
    ch4->InputChan0=10;
    ch4->InputChan1=9;
    ch4->OutputChan0=8;
    ch4->OutputChan1=9;
    ch4->MasterAxis=-1;
    ch4->LimitSwitchOptions=0x100;
    ch4->LimitSwitchNegBit=0;
    ch4->LimitSwitchPosBit=0;
    ch4->SoftLimitPos=1e+09;
    ch4->SoftLimitNeg=-1e+09;
    ch4->InputGain0=-1;
    ch4->InputGain1=1;
    ch4->InputOffset0=0;
    ch4->InputOffset1=0;
    ch4->OutputGain=1;
    ch4->OutputOffset=0;
    ch4->SlaveGain=1;
    ch4->BacklashMode=BACKLASH_OFF;
    ch4->BacklashAmount=0;
    ch4->BacklashRate=0;
    ch4->invDistPerCycle=1;
    ch4->Lead=0;
    ch4->MaxFollowingError=200;
    ch4->StepperAmplitude=35;
    ch4->Position = 0;
    ch4->Dest = 0;
    ch4->iir[0].B0=1;
    ch4->iir[0].B1=0;
    ch4->iir[0].B2=0;
    ch4->iir[0].A1=0;
    ch4->iir[0].A2=0;
 
    ch4->iir[1].B0=1;
    ch4->iir[1].B1=0;
    ch4->iir[1].B2=0;
    ch4->iir[1].A1=0;
    ch4->iir[1].A2=0;
 
    ch4->iir[2].B0=1;
    ch4->iir[2].B1=0;
    ch4->iir[2].B2=0;
    ch4->iir[2].A1=0;
    ch4->iir[2].A2=0;
 
    DefineCoordSystem(4,-1,-1,-1); //define ch4 as x
    WritePWMR(8,0);    // write PWM directly to channel 8, with power +-400
    while(1)
    {
 
        int output = (ch4->Output);
        WaitNextTimeSlice();
        if (0 == ch4->Enable)
            WritePWMR(8,0);    // write PWM directly to channel 8, with power +-400
        else
            WritePWMR(8,output);    // write PWM directly to channel 8, with power +-400
     
    }     
     
}

Your code looks reasonable to me.  The Step Response Screen should work after that code is running.  Make sure all the screens (Config, Filters, and Step Response) are set with matching parameters to your C code.  The simplest thing would be to upload the parameters to the screens after the C Program has been executed.   Of course you should be tuning the same KFLOP Axis channel #4.  Not quite sure why you are using Axis Channel #4 instead of #0 but that shouldn't matter.

Your system is basically a torque mode system (vs a velocity control) which is theoretically unstable with only P gain.  The motor power (acceleration) will continue until it passes the target position pretty much guaranteeing overshoot, oscillation, and instability.  It will only be stable if there is enough physical friction.  Phase lead is required to get a more stable system by either adding D gain (usually a multiple of the P gain) or by adding an appropriate lead/lag filter/compensator.

HTH

Regards

TK

 

I mounted the motor on the CNC and it works pretty well. However, I don't seem to be able to use the step response screen. I have been tuning the loop by trial and error, setting the parameters in the c code. However, setting a motion in the step response screen causes the motor not to move at all (small movements), or run away (large movements) - kind of like when the servo gain is inverted. However, the thing happens independent of servo gain sign - and anyway, the loop works when everything is set in code so the gain there is correct. I am probably overflowing a variable somewhere or something.

Here the code that works well enough to let me jog the axis in kmotionCNC:

#include "KMotionDef.h"
 
int main() 
{
    WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT0,9);  // current limit
    WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT1,9);  // current limit
        WriteSnapAmp(SNAP0+SNAP_SUPPLY_CLAMP0 ,SNAP_CONVERT_VOLTS_TO_ADC(70.0));
    WriteSnapAmp(SNAP0+SNAP_SUPPLY_CLAMP1 ,SNAP_CONVERT_VOLTS_TO_ADC(70.0));
    WriteSnapAmp(SNAP0+SNAP_SUPPLY_CLAMP_ENA0,1);
    WriteSnapAmp(SNAP0+SNAP_SUPPLY_CLAMP_ENA1,1);
     
    ch4->InputMode=ENCODER_MODE;
    ch4->OutputMode=NO_OUTPUT_MODE;
    ch4->Vel=10000;
    ch4->Accel=1e+05;
    ch4->Jerk=1e+07;
    ch4->P=10.0;
    ch4->I=0.001;
    ch4->D=0;
    ch4->FFAccel=0;
    ch4->FFVel=0;
    ch4->MaxI=200;
    ch4->MaxErr=1e+06;
    ch4->MaxOutput=400;
    ch4->DeadBandGain=1;
    ch4->DeadBandRange=0;
    ch4->InputChan0=10;
    ch4->InputChan1=9;
    ch4->OutputChan0=8;
    ch4->OutputChan1=9;
    ch4->MasterAxis=-1;
    ch4->LimitSwitchOptions=0x100;
    ch4->LimitSwitchNegBit=0;
    ch4->LimitSwitchPosBit=0;
    ch4->SoftLimitPos=1e+09;
    ch4->SoftLimitNeg=-1e+09;
    ch4->InputGain0=-1;
    ch4->InputGain1=1;
    ch4->InputOffset0=0;
    ch4->InputOffset1=0;
    ch4->OutputGain=1;
    ch4->OutputOffset=0;
    ch4->SlaveGain=1;
    ch4->BacklashMode=BACKLASH_OFF;
    ch4->BacklashAmount=0;
    ch4->BacklashRate=0;
    ch4->invDistPerCycle=1;
    ch4->Lead=0;
    ch4->MaxFollowingError=200;
    ch4->StepperAmplitude=35;
    ch4->Position = 0;
    ch4->Dest = 0;
    ch4->iir[0].B0=1;
    ch4->iir[0].B1=0;
    ch4->iir[0].B2=0;
    ch4->iir[0].A1=0;
    ch4->iir[0].A2=0;
 
    ch4->iir[1].B0=1;
    ch4->iir[1].B1=0;
    ch4->iir[1].B2=0;
    ch4->iir[1].A1=0;
    ch4->iir[1].A2=0;
 
    ch4->iir[2].B0=1;
    ch4->iir[2].B1=0;
    ch4->iir[2].B2=0;
    ch4->iir[2].A1=0;
    ch4->iir[2].A2=0;
 
    DefineCoordSystem(4,-1,-1,-1); //define ch4 as x
    WritePWMR(8,0);    // write PWM directly to channel 8, with power +-400
    while(1)
    {
 
        int output = (ch4->Output);
        WaitNextTimeSlice();
        if (0 == ch4->Enable)
            WritePWMR(8,0);    // write PWM directly to channel 8, with power +-400
        else
            WritePWMR(8,output);    // write PWM directly to channel 8, with power +-400
     
    }     
     
}

The problem was a lingering parameter in the config screen. Everything works great now. Thanks!

Great thanks for posting back.

Regards

TK

 

The problem was a lingering parameter in the config screen. Everything works great now. Thanks!

Attachments :

P3.0-15043.png
P2.3-15043.png
P2.2c-15043.png
P2.2b-15043.png
P2.2a-15043.png

I have run into erratic behavior I cannot explain while tuning the servos.

As I go from PID = 2.0, 0, 0 to 2.3 ,0 ,0 the axis starts acting as if I overflow a variable or something somewhere.

Look the the attached step response screens. At P=2.0, there is never a problem, as I increase P from there the behavior gets erratic, and by the time P=3.0, the axis wont move at all aside from a small audible click.

How do I track down what is happening?

I suspect you are simply exceeding peak current limits and SnapAmp is disabling.  You will probably see the fault LED on SnapAmp Flash.

When SnapAmp current faults it disables the output for ~ 1/2 second and then resets to try again.

You can see where the encoder (red) stops moving is where the fault occurs and sometimes where it starts moving again after SnapAmp resets.

It would probably be helpful to plot motor current also.   Although if I recall you are using motors expected to have huge current ripples.  So I'm not sure how valid the measurements would actually be.

As you increase P gain then the current rises faster and to higher levels so it is more likely to fault.

It usually doesn't make sense to test using the "Step" test for exactly this reason.  An instant 100 count error wouldn't ever occur under normal conditions unless something catastrophic happened like hitting a brick wall at high speed in which case you would want the system to disable.  I realize that much of the theory is based on response to a step function and that is why it is included (and the screen is named such), but practically it usually doesn't make sense.  Unless the step size is very small and on the order of the size of errors the system would be normally correcting.

Use the "Move" Button which is a more realistic test.  And/or increase your peak current limits to avoid the fault.

HTH
Regards
TK 

 

I have run into erratic behavior I cannot explain while tuning the servos.

As I go from PID = 2.0, 0, 0 to 2.3 ,0 ,0 the axis starts acting as if I overflow a variable or something somewhere.

Look the the attached step response screens. At P=2.0, there is never a problem, as I increase P from there the behavior gets erratic, and by the time P=3.0, the axis wont move at all aside from a small audible click.

How do I track down what is happening?

Awesome! That makes a lot of sense!

Thanks for the help!!

Thanks again for the help. Here a video of the system working:
https://youtu.be/O3zEfU5BS2U

Question: The achieved feedrate in the circular interpolation according to KmotionCNC is always significantly below the commanded one - except for very slow feeds. Is that expected behavior, or did I mess up a setting?

Also for long linear moves of a single axis the feed rate oscillates between the commanded rate and ~20% lower at about a 1 Hz rate. Is that normal too?

Hi Jan,

It might be an acceleration limitation. It takes high acceleration to do a tight curve at high speed.

What is the Trajectory Planner Accelerations Set at?

What is the radius of the circle?

What is your commanded feedrate?

A linear move should run at the specified feedrate and not vary.

Please post all of your Trajectory Planner Settings.  How are you determining the feedrate?

Regards
TK

 

Thanks again for the help. Here a video of the system working:
https://youtu.be/O3zEfU5BS2U

Question: The achieved feedrate in the circular interpolation according to KmotionCNC is always significantly below the commanded one - except for very slow feeds. Is that expected behavior, or did I mess up a setting?

Also for long linear moves of a single axis the feed rate oscillates between the commanded rate and ~20% lower at about a 1 Hz rate. Is that normal too?

Then I have something configured wrong, because I have linear motion at varying feed rate. I made a sample video here:
https://youtu.be/Az8WMzk-foM

In order to remove binding or the motor, I pulled out a plain THK linear actuator with a stepper motor. This is then configured as an open loop stepper.

Here, I am first jogging the axis, and then running the following gcode in KMotionCNC:

G20
M98 P100 L2(Call the Subroutine 2 times)
M2 (Stop)

O100 (Subroutine Label of 100)
F60
G1 Z0.0
G1 Z8.0
M99


The 'move' command in the KMotion step response screen as well as the jogging in KMotionCNC yield very smooth motion. However, when using Gcode in KMotionCNC, I get linear moves with oscillating speed, which is audible in the video. Here, the F60 yields actual move speeds of F38-42 according to the KMotionCNC screen. When jogging, I get a rock solid F60...

It does not matter at which feed rate I actually do this. If I configure KMotionCNC with jogging speed of F50, the jog will be at 50.0, while the gcode with F50 will result in oscillation around 32-38.

Thanks for any input!

Hi Jan,

We asked for your Trajectory Planner settings.  I don't see that you posted them.

It may be that you have unusually low Acceleration or Jerk settings combined with low motion buffering time could cause something like that.  Its somewhat hard to explain but KFLOP has "anti-buffer underflow protection" where it automatically slows down if it thinks it is running dangerously low on motion data.  This should never happen unless your PC is excessively overloaded but if it for some reason  it does,  it is better to slow than to abruptly run out of data.  However if for example you configure KFLOP so it could take 1.2 seconds to stop and at the same time restrict it from buffering more than one second of data, then KFLOP can be in a continuous state where it says OMG I better slow down to be sure I could safely stop before running out of data.

Jogging vs Feeding use different parameters.  Have you evaluated and determined proper parameters for your system?  You might read this article:

http://www.dynomotion.com/wiki/index.php?title=Main_Page#Velocity.2C_Acceleration.2C_and_Jerk

Regards
TK

 

Then I have something configured wrong, because I have linear motion at varying feed rate. I made a sample video here:
https://youtu.be/Az8WMzk-foM

In order to remove binding or the motor, I pulled out a plain THK linear actuator with a stepper motor. This is then configured as an open loop stepper.

Here, I am first jogging the axis, and then running the following gcode in KMotionCNC:

G20
M98 P100 L2(Call the Subroutine 2 times)
M2 (Stop)

O100 (Subroutine Label of 100)
F60
G1 Z0.0
G1 Z8.0
M99


The 'move' command in the KMotion step response screen as well as the jogging in KMotionCNC yield very smooth motion. However, when using Gcode in KMotionCNC, I get linear moves with oscillating speed, which is audible in the video. Here, the F60 yields actual move speeds of F38-42 according to the KMotionCNC screen. When jogging, I get a rock solid F60...

It does not matter at which feed rate I actually do this. If I configure KMotionCNC with jogging speed of F50, the jog will be at 50.0, while the gcode with F50 will result in oscillation around 32-38.

Thanks for any input!

Thanks for the response!

I am sorry for forgetting the data you asked for; see below...

I have been using the wiki you referred to to tune the axes. I did notice the note that

"The KFLOP parameters are used for 3rd order motions.   These include things like:  Jogging, Homing, and GCode Rapids (G0).  The units in KFLOP are in counts or steps.

The KMotionCNC parameters are used for 2nd order (infinite Jerk) coordinated motion paths.  These are GCode G1,G2,G3 continuous paths."

So, for another test, I set everything up with extremely large Jerk so that G0/G1 should be identical.

With the following settings:

Ok, in Kmotion I have
V = 317.5 cts/sec
A = 3175 cts/sec/sec
J = 1e+12 cts/sec/sec

and in KMotionCNC

axis : 63.5 cts/inch
V = 5 inch/sec (317.5 cts/sec)
A = 50 inch/sec/sec (3175 cts/sec/sec )

So I see the following behavior:

- step/response screen move yields very smooth motion

- jog in KMotion yields very smooth motion with the screen displaying F 300.0 all the way (as expected)

- moving using G0 for a 17 inch move starts out with smooth motion for about 7 inches at F 300.0 but then slows down, speeds up and then slows down again all in about the last 10 inches or so

- moving using a G1 for a 17 inch move commanded with F300 starts the oscillating behavior right away with actual feed rates varying between 200 and 225.

I also went ahead and shut down the computer, unplugged the kflop and then brought everything back up online and tested again (just to be sure). No change though...

Hi Jan,

Please include all your settings - Trajectory Planner, KFLOP Axes, Coordinate System Definition.  Everything someone would need to exactly replicate the scenario (screen shot of TP settings and Init C file).

That axis can indeed stop pretty fast (~ 0.1sec).    But you didn't tell us what your lookahead time setting is or how the other axes are configured.  The guaranteed time to safely stop is based on the axis that takes the longest time to stop.  The buffer underflow risk is based on time not lines of GCode.  It might be over several or hundreds of motion segments.

Regards
TK

 

Thanks for the response!

I am sorry for forgetting the data you asked for; see below...

I have been using the wiki you referred to to tune the axes. I did notice the note that

"The KFLOP parameters are used for 3rd order motions.   These include things like:  Jogging, Homing, and GCode Rapids (G0).  The units in KFLOP are in counts or steps.

The KMotionCNC parameters are used for 2nd order (infinite Jerk) coordinated motion paths.  These are GCode G1,G2,G3 continuous paths."

So, for another test, I set everything up with extremely large Jerk so that G0/G1 should be identical.

With the following settings:

Ok, in Kmotion I have
V = 317.5 cts/sec
A = 3175 cts/sec/sec
J = 1e+12 cts/sec/sec

and in KMotionCNC

axis : 63.5 cts/inch
V = 5 inch/sec (317.5 cts/sec)
A = 50 inch/sec/sec (3175 cts/sec/sec )

So I see the following behavior:

- step/response screen move yields very smooth motion

- jog in KMotion yields very smooth motion with the screen displaying F 300.0 all the way (as expected)

- moving using G0 for a 17 inch move starts out with smooth motion for about 7 inches at F 300.0 but then slows down, speeds up and then slows down again all in about the last 10 inches or so

- moving using a G1 for a 17 inch move commanded with F300 starts the oscillating behavior right away with actual feed rates varying between 200 and 225.

I also went ahead and shut down the computer, unplugged the kflop and then brought everything back up online and tested again (just to be sure). No change though...

I understand your buffer underflow approach, but it's hard to believe that that is happening with < 10 lines of gcode, isn't it?

Thanks again!

---In DynoMotion@yahoogroups.com, <tk@...> wrote :

Hi Jan,

We asked for your Trajectory Planner settings.  I don't see that you posted them.

It may be that you have unusually low Acceleration or Jerk settings combined with low motion buffering time could cause something like that.  Its somewhat hard to explain but KFLOP has "anti-buffer underflow protection" where it automatically slows down if it thinks it is running dangerously low on motion data.  This should never happen unless your PC is excessively overloaded but if it for some reason  it does,  it is better to slow than to abruptly run out of data.  However if for example you configure KFLOP so it could take 1.2 seconds to stop and at the same time restrict it from buffering more than one second of data, then KFLOP can be in a continuous state where it says OMG I better slow down to be sure I could safely stop before running out of data.

Jogging vs Feeding use different parameters.  Have you evaluated and determined proper parameters for your system?  You might read this article:

http://www.dynomotion.com/wiki/index.php?title=Main_Page#Velocity.2C_Acceleration.2C_and_Jerk

Regards
TK

On 10/1/2017 5:43 PM, homeloan@... [DynoMotion] wrote:

 

Then I have something configured wrong, because I have linear motion at varying feed rate. I made a sample video here:
https://youtu.be/Az8WMzk-foM

In order to remove binding or the motor, I pulled out a plain THK linear actuator with a stepper motor. This is then configured as an open loop stepper.

Here, I am first jogging the axis, and then running the following gcode in KMotionCNC:

G20
M98 P100 L2(Call the Subroutine 2 times)
M2 (Stop)

O100 (Subroutine Label of 100)
F60
G1 Z0.0
G1 Z8.0
M99


The 'move' command in the KMotion step response screen as well as the jogging in KMotionCNC yield very smooth motion. However, when using Gcode in KMotionCNC, I get linear moves with oscillating speed, which is audible in the video. Here, the F60 yields actual move speeds of F38-42 according to the KMotionCNC screen. When jogging, I get a rock solid F60...

It does not matter at which feed rate I actually do this. If I configure KMotionCNC with jogging speed of F50, the jog will be at 50.0, while the gcode with F50 will result in oscillation around 32-38.

Thanks for any input!

Attachments :

I see. I am attaching a screenshot of the trajectory planner settings as well as my configuration .c file.

Hi Jan,

As suspected KFLOP is configured for X and Y to require more than 2 seconds to stop with:

    ch0->Vel=100000;
    ch0->Accel=50000;

    ch1->Vel=100000;
    ch1->Accel=50000;

20 times slower than Z while only permitting 1 second of look ahead.

Its like driving with bad brakes in fog with 10 feet of visibility.  How fast would you drive?

I suppose it isn't intuitive why when moving only in Z why X and Y matter.  Clearly they shouldn't.  But it would be very difficult to analyze the upcoming several seconds of motion with all trajectory possibilities to determine if things were safe.  So KFLOP simply does a worst case analysis.   Under normal circumstances there isn't an issue.    ie We know if we had to we can always stop in 0.1sec, and we have 2 seconds of clear road ahead, so no worries...

Regards
TK  

 

I see. I am attaching a screenshot of the trajectory planner settings as well as my configuration .c file.

Ha, that is very subtle, but makes perfect sense! And I can confirm that both reducing the velocity of the unused axes or increasing the lookahead time solve the issue.

Thank you once again for the world-class support!

Thank you for posting back.  Not everyone takes the time.
Regards
TK

 

Ha, that is very subtle, but makes perfect sense! And I can confirm that both reducing the velocity of the unused axes or increasing the lookahead time solve the issue.

Thank you once again for the world-class support!